Bad Database Security

Comments 0

Share to social media

The Daily WTF recently reported that the Sexual and Violent Offender Registry of Oklahoma had to shut down its website for ‘routine maintenance’. It turns out that this routine maintenance was necessary because 10,597 social security numbers from sex offenders had been downloaded, by SQL injection.

Sadly, this is not an isolated case. There has been a recent spate of SQL injection attacks, most of which have been blamed on IIS. However, closer inspection, in this case, reveals that the JavaScript file responsible was merely testing for all the well-known security loopholes, many of which are open due to poor database security.

SQL injection attacks rely on several fundamental, but frustratingly common mistakes:

  1. Allow the end-user or the logins assigned to the website direct access to the base tables.
  2. Perform inadequate checking of input (inadequate type handling, incorrectly filtered escape characters)
  3. Perform no parameterisation of input in the calls to the database.

Without wishing to re-open an old debate, Simple-Talk has long advised that the interface between the application and the SQL Server database should always use stored procedures. However, many are still resistant to the idea.

The attacker who is out to get data also needs to have it delivered on-screen, as was conveniently provided in the Oklahoma incident. Database errors should never be displayed on-screen in a production system. On the contrary, all errors, even 404 errors, should be logged and emailed to production staff as part of the general alerting system for any corporate application.

No longer can developers sit back in their chairs once an application is shown to perform to specification. They must prove that their application can counter all current security threats and be able to report when an attack happens. When implemented, you may be shocked by the vast number of attempted intrusions to which the typical application is subjected.

As always, your views are encouraged. Add your comments to this blog and the three best entries will win a Simple-Talk gift pack, complete with polo shirt and much-coveted USB dongle.

Cheers,

Tony.

Load comments

About the author

Tony Davis

See Profile

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page.

As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management.

In his spare time, he enjoys running, football, contemporary fiction and real ale.